home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group93b.txt / 000077_icon-group-sender _Mon May 10 23:34:34 1993.msg < prev    next >
Internet Message Format  |  1993-06-16  |  3KB
  1. Received: by cheltenham.cs.arizona.edu; Tue, 11 May 1993 06:08:56 MST
  2. Date: Mon, 10 May 93 23:34:34 PDT
  3. Message-Id: <9305110634.AA11851@internal.apple.com>
  4. To: icon-group@cs.arizona.edu
  5. From: nevin@apple.com (Nevin ":-]" Liber)
  6. X-Sender: nevin@130.43.2.2
  7. Subject: Re: runtime debugger and the Icon fan club.
  8. Cc: stephen@acm.org (Stephen P Spackman)
  9. Status: R
  10. Errors-To: icon-group-errors@cs.arizona.edu
  11.  
  12. Stephen Spackman (stephen@acm.org) writes:
  13. >I think the only reason you say this is that you are used to Icon. In
  14. >Algol68 this was the preferred method, and indeed the Gnu C formatting
  15. >standard follows this venerable tradition. The idea is that this:
  16. >
  17. >        ( a
  18. >        * broof
  19. >        * cl
  20. >        )
  21. >
  22. >is much clearer than this:
  23. >
  24. >        ( a *
  25. >          broof *
  26. >          cli )
  27.  
  28. I disagree.  At first glance, I and most other C programmers would
  29. interpret the expression "* broof" as a dereference of the pointer broof. 
  30. I would have to go back and find the type of broof (and that might require
  31. going through many headers full of typedefs) before I'd be sure of what was
  32. intended here.
  33.  
  34. >(This isn't the optimal strategy for C, because it chooses to
  35. >make ; a statement *terminator* rather than a *separator* as God
  36. >intended
  37.  
  38. I beleive that HCI (human computer interface) folks have done studies that
  39. show that it is easier for programmers to have semicolons as terminators
  40. than as seperators.  I've always found that it always takes a little effort
  41. in Pascal (where semicolons are seperators) to determine whether or not a
  42. semicolon is even allowed in certain situations (you have to always think
  43. about what it MEANS), where in C it is almost a no-brainer (you are allowed
  44. to put them after any statement without changing the semantics of the code
  45. you are writing).  In Icon it is a no-brainer since in practice I've never
  46. actually had occasion to use one.
  47.  
  48. >That is, you'd really like this to work too:
  49. >
  50. >        { something
  51. >        ; something else
  52. >        ; another something
  53. >        }
  54. >
  55. >but it doesn't because C goes and demands an extra semicolon at the
  56. >end. C's a mess.)
  57.  
  58. I've written a lot of C (and even some Pascal/Modula 2) code in my time,
  59. and I've never wanted to write code like this (although ANSI C does have
  60. some annoying things like allowing an extra comma at the end of a structure
  61. initialisation list, but disallowing it at the end of an enumeration list,
  62. but I digress).  The only time I've ever needed to remotely do something
  63. like this was for an MPW (Macintosh Programmer's Workshop -- a development
  64. environment for Macintosh) script I was writing which needed to call a
  65. different tool (StreamEdit, for those who might care) on itself from within
  66. the script (StreamEdit considers semicolon as a comment character), but
  67. this was only to make up for deficiencies in the scripting language (no
  68. "here" documents, for those people familiar with Unix shells).  It
  69. certainly isn't the norm, and would need a very good reason before it could
  70. pass even a simple code review.
  71. ___
  72. NEVIN ":-)" LIBER,      Blue Meanie, Macintosh System Software
  73.  email:     nevin@apple.com        paper:  Apple Computer, Inc.
  74.  voice:     (408) 974-MIX1                 2 Infinite Loop, MS: 302-4Q
  75.  AppleLink: BADENOV                        Cupertino, CA 95014
  76.  
  77.